In a client-services architecture, a client system, such as a computer, may call an application, such as a program, a service, or a web service, at a server to interact with the application through the Internet or an intranet. A service, such as a web service, is an application (or program) that makes itself available over the Internet or an intranet, uses standardized messaging, such as XML (extensible Markup Language) and Simple Object Access Protocol (SOAP), and uses some type of location mechanism, such as UDDI (Universal Description, Discovery, and Integration), to locate the service and its public Application Program Interface (API).
To call a service through the Internet or intranet, the client system makes a call (e.g., using messages) through an API, which defines the way the client communicates with the service. The service instantiates objects, such as business objects, in response to the API call. The term “object” refers to a data structure including at least one of data and related methods, while the phrase “business object” refers to an object used in connection with a business process or task.
An example of a service is a “catalog” service, which can be called through the Internet by a client system. The catalog service may allow a user at a client system to view and purchase products. FIG. 5 depicts some of the business objects that may be associated with the catalog service. The business objects may, for example, correspond to data listing each product (e.g., business object 402), product descriptions 404, available quantity 406 (e.g., quantity of products available in stock), and quantity ordered 408. In the example of FIG. 5, business objects 404-408 are so-called “dependent” business objects since they depend from business object 402.
When a client system calls the catalog service, the catalog service instantiates business objects 402-408, allowing objects 402-408 to retrieve from a database, data and methods associated with those objects. The retrieved data may then be buffered for the transaction with the client system. At some point (e.g., during or after the transaction), the business objects would be saved in a database 196 for persistent storage.
In some instances, business objects 402-408 may need to be sent, received, copied, replicated, updated, or transferred from database 196 to another database (or persistence mechanism). However, in many cases, business objects 402-408 cannot simply be sent from, for example, one database to another database because the size and complexity of real-world business objects may result in errors at the receiving and sending applications (e.g., database applications). There thus continues to be a need to provide mechanisms to send, receive, copy, replicate, update, and/or transfer business objects among applications.